Skip to main content
Feedback

Creating an order processing with Event Streams

A manufacturing company wants to process new orders from their eCommerce platform in near real-time. When an order is placed, an event should be triggered, and that order data should be pushed through Boomi.

Architectural Overview

The goal is to decouple the actions that follow an order placement. Instead of a single, monolithic process, a publisher process will send an "Order Placed" event to a central topic. Multiple independent subscriber processes will listen to this topic, each performing a specific action: updating the ERP, notifying the warehouse, and emailing the customer.

This publish/subscribe model ensures that if one system (like the warehouse API) is temporarily down, the other processes (like ERP updates and customer emails) are not affected.

Step 1: Configure the Event Stream Topic & Subscriptions

First, you'll create the central message channel (the topic) and the dedicated queues for each downstream system (the subscriptions).

  1. Log into the Boomi Platform and navigate to Services -> Event Streams.

  2. Select the appropriate environment and click Add a Topic.

  3. Configure the topic:

  • Topic Name: OrderPlaced

  • Description: A stream for processing newly placed eCommerce orders.

  1. Click on the newly created OrderPlaced topic to add subscriptions. Create three separate subscriptions:

  • Subscription Name: ERP_Subscription

  • Subscription Name: Warehouse_Subscription

  • Subscription Name: Email_Subscription

  1. Click Save & Deploy.

Step 2: Build the Publisher Process

This process simulates a new order being placed and publishes it as an event to the OrderPlaced topic.

  1. In the Boomi Integration canvas, create a new process named Publish_Order_Event.

  2. Start Shape: Use a No Data start shape for manual testing. (Alternatively, use a Web Services Server listener to accept real-time order data from your eCommerce platform).

  3. Message Shape: Define the order data structure. This will be the body of the event.

  4. JSON

{
  "orderId": "ORD-12345",
  "customerEmail": "jane.doe@example.com",
  "items": [
    {
      "sku": "ABC-LG-RED",
      "quantity": 2,
      "price": 29.99
    },
    {
      "sku": "XYZ-SM-BLK",
      "quantity": 1,
      "price": 89.99
    }
  ],
  "totalAmount": 149.97
}
  1. Event Streams Connector Shape:

  • Action: Send

  • Connection: Your Event Streams Connection

  • Operation: Configure the operation to select the OrderPlaced topic.

  1. Connect the shapes and add a Stop Shape.

Step 3: Build the Subscriber Processes

Now, create three separate, independent processes that listen for events from the OrderPlaced topic.

  1. Subscriber 1: ERP Ingestion

  • Process Name: Subscribe_Order_To_ERP

  • Start Shape: Use the Event Streams connector.

    • Action: Listen

    • Topic: OrderPlaced

    • Subscription: ERP_Subscription

  • Connector Shape: Use the NetSuite (or other ERP) connector.

    • Action: UPSERT

    • Map the incoming JSON data from the event to the fields in your NetSuite Sales Order record.

  1. Subscriber 2: Warehouse Notification

  • Process Name: Subscribe_Order_To_Warehouse

  • Start Shape: Use the Event Streams connector.

    • Action: Listen

    • Topic: OrderPlaced

    • Subscription: Warehouse_Subscription

  • Connector Shape: Use the HTTP Client connector.

    Configure it to POST the order data to your warehouse system's API endpoint (e.g., /api/v1/new-shipment).

  1. Subscriber 3: Customer Email Confirmation

  • Process Name: Subscribe_Order_Confirmation_Email

  • Start Shape: Use the Event Streams connector.

    • Action: Listen

    • Topic: OrderPlaced

    • Subscription: Email_Subscription

  • Mail (SMTP) Connector Shape:

    Configure the connection to your email server.

    Set the To Address using the customerEmail field from the incoming event profile.

    Set the Subject and Body dynamically using fields like orderId and totalAmount.

  1. Step 4: Deploy and Test the Solution

  2. Deploy the publisher process (Publish_Order_Event) and all three subscriber processes to your environment.

  3. Execute the Publish_Order_Event process manually from the Build tab or by triggering its endpoint.

  4. Navigate to Manage -> Process Reporting. You should see four successful, independent process executions:

    One execution of Publish_Order_Event.

    One execution for each of the three subscriber processes (...To_ERP, ...To_Warehouse, ...Confirmation_Email).

This confirms that the single event was successfully consumed by all three independent subscribers.

Benefits Achieved

By implementing this architecture, the manufacturing company achieves significant advantages:

  • Decoupling: The systems that create orders are separate from the systems that process them. The ERP, warehouse, and email systems are not dependent on each other.

  • Resilience: If the warehouse API is down, the ERP update and customer email are still processed successfully. The failed warehouse message can be reprocessed later without affecting other workflows.

  • Scalability: You can easily add more subscriber processes (e.g., a fraud detection service or an analytics database) without modifying the existing publisher or subscribers.

On this Page